[Database Probe]
Alert Count=70
Zone 1 refresh=1
Zone 2 refresh=1
Zone 3 refresh=1
Zone 4 refresh=4
Zone 5 refresh=4
Redo Alert Level=51
Datafiles Alert Level=81
Gauge color=32768
Gauge warning color=255
UseExpressionForHint=0
[Database Probe Alert_1]
Name=Async IO Check
Desc=Generally speaking, always set DISK_ASYNC_IO = TRUE. Even when DBWR_IO_SLAVES > 0 or DB_WRITER_PROCESSES > 1. Only set DISK_AYNC_IO = FALSE when the platform does not support asynchronous I/O or implements it inefficiently.
Active=1
AlertControl=Async_IO_
LeftSideExpr=" Async_IO "
RightSideExpr="0"
RelationalOp==
Refreshes=1
[Database Probe Alert_2]
Name=DBWR Proc Slave Check
Desc=Excessive DBWR activity has been requested by setting DB_WRITER_PROCESSES > 1 and DBWR_IO_SLAVES > 0. Generally speaking, you should either use multiple DBWR processes or DBWR slaves - but not both.
Active=1
AlertControl=DBWR
LeftSideExpr="( DBWR_Count - 1 ) * DBWR_Slaves "
RightSideExpr="0"
RelationalOp=>
Refreshes=1
[Database Probe Alert_3]
Name=DBWR Proc Count High
Desc=Number of DBWR processes > 10 (the limit is 20). Verify that your hardware can actually handle that high an IO load.
Active=1
AlertControl=DBWR_Count_
LeftSideExpr=" DBWR_Count "
RightSideExpr="10"
RelationalOp=>
Refreshes=1
[Database Probe Alert_4]
Name=DBWR Slave Count High
Desc=Number of DBWR slave processes > 10 (there is no hard limit). Verify that your hardware can actually handle that high an IO load.
Active=1
AlertControl=DBWR_Slaves_
LeftSideExpr=" DBWR_Slaves "
RightSideExpr="10"
RelationalOp=>
Refreshes=1
[Database Probe Alert_5]
Name=Auditing
Desc=Auditing has been activated via the INIT.ORA setting or an ALTER command. While there may be security requirements for doing this, gathering such internal database operations information does impose minimal overhead.
Active=1
AlertControl=Overhead_Auditing
LeftSideExpr=" Auditing_InitORA  "
RightSideExpr="0"
RelationalOp=>
Refreshes=1
[Database Probe Alert_6]
Name=Timed OS Statistics
Desc=Timed OS Statistics has been activated via the INIT.ORA or an ALTER command. While there may be tuning reasons for doing this, gathering such operating system statistics is very expensive.
Active=1
AlertControl=Overhead_Stats_OS
LeftSideExpr="  Timed_Stats_OS_InitORA  "
RightSideExpr="0"
RelationalOp=>
Refreshes=1
[Database Probe Alert_7]
Name=Timed Statistics
Desc=Timed Statistics has been activated via the INIT.ORA or an ALTER command. While there may be tuning reasons for doing this, gathering such internal database statistics can be expensive.
Active=1
AlertControl=Overhead_Stats_DB
LeftSideExpr=" Timed_Stats_DB_InitORA  "
RightSideExpr="0"
RelationalOp=>
Refreshes=1
[Database Probe Alert_8]
Name=Oracle Trace
Desc=Oracle Trace has been enabled via the INIT.ORA or an ALTER command. While there may be tuning reasons for doing this, permitting such internal database trace collections can be expensive.
Active=1
AlertControl=Overhead_Trace_Oracle
LeftSideExpr=" Trace_Enabled_Oracle_InitORA  "
RightSideExpr="0"
RelationalOp=>
Refreshes=1
[Database Probe Alert_9]
Name=SQL Trace
Desc=SQLTrace has been enabled via the INIT.ORA or an ALTER command. While there may be tuning reasons for doing this, gathering such detailed SQL trace information imposes a severe performance impact.
Active=1
AlertControl=Overhead_Trace_SQL
LeftSideExpr=" Trace_Enabled_SQL_InitORA  "
RightSideExpr="0"
RelationalOp=>
Refreshes=1
[Database Probe Alert_10]
Name=Statistics Level
Desc=Statistics Level has been activated via the INIT.ORA or an ALTER command. While there may be tuning reasons for doing this, gathering both operating system and database statistics is expensive.
Active=1
AlertControl=Overhead_Stats_Level
LeftSideExpr=" Stats_Level_InitORA  "
RightSideExpr="0"
RelationalOp=>
Refreshes=1
[Database Probe Alert_11]
Name=Lock SGA
Desc=LOCK_SGA, which locks the entire SGA into physical memory, is not currently enabled. It is usually advisable to lock the SGA into real (physical) memory, especially if the use of virtual memory would include storing some of the SGA using disk space. This parameter is ignored on platforms that do not support it. This does not work for Oracle database instances on Windows.
Active=1
AlertControl=SGA_Lock_
LeftSideExpr=" SGA_Lock "
RightSideExpr="0"
RelationalOp==
Refreshes=1
[Database Probe Alert_12]
Name=Session Cached Cursors
Desc=SESSION_CACHED_CURSORS, which lets you specify the number of session cursors to cache, is set to zero. Repeated parse calls of the same SQL statement cause the session cursor for that statement to be moved into the session cursor cache. Subsequent parse calls will find the cursor in the cache and need not reopen the cursor. Oracle uses a least recently used algorithm to remove entries in the session cursor cache to make room for new entries when needed.
Active=1
AlertControl=SGA_Session_Cached_Cursors
LeftSideExpr=" Session_Cached_Cursors "
RightSideExpr="0"
RelationalOp==
Refreshes=1
[Database Probe Alert_13]
Name=Pre Page SGA
Desc=PRE_PAGE_SGA, which determines whether all SGA pages are brought into memory at instance startup, is currently not enabled. Operating system page table entries are then prebuilt for each page of the SGA. The resulting decrease in disk I/O may be offset by performance degradation in other areas. Therefore, this parameter is most useful on systems that have sufficient memory to hold all the SGA pages without degrading performance in other areas.
Active=1
AlertControl=SGA_Prepage
LeftSideExpr=" Prepage "
RightSideExpr="0"
RelationalOp==
Refreshes=1
[Database Probe Alert_14]
Name=Cursor Space for Time
Desc=CURSOR_SPACE_FOR_TIME, which lets you use more space for cursors in order to save time, is currently not enabled. It affects both the shared SQL area and the client's private SQL area. When set to TRUE, then shared SQL areas are kept pinned in the shared pool. As a result, shared SQL areas are not aged out of the pool as long as an open cursor references them. Because each active cursor's SQL area is present in memory, execution is faster. However, the shared SQL areas never leave memory while they are in use. Therefore, you should set this parameter to TRUE only when the shared pool is large enough to hold all open cursors simultaneously.
Active=1
AlertControl=SGA_Cursor_Space_For_Time
LeftSideExpr=" Cursor_space_for_time "
RightSideExpr="0"
RelationalOp==
Refreshes=1
[Database Probe Alert_15]
Name=Java Pool Too Small
Desc=JAVA_POOL_SIZE, which specifies the size in bytes of the Java pool from which the Java memory manager allocates most Java state during runtime execution, is below Oracle's recommended minimum of 10-50 MB for dedicated servers and up to 100 MB for shared servers. This memory includes the shared in-memory representation of Java method and class definitions, as well as the Java objects that are migrated to the Java session space at end-of-call. Note - there is another alert you can use if you're not using Java.
Active=1
AlertControl=Java_Pool_Megs_
LeftSideExpr=" Java_Pool_Megs "
RightSideExpr="10"
RelationalOp=<
Refreshes=1
[Database Probe Alert_16]
Name=Java Pool Not Needed
Desc=JAVA_POOL_SIZE, which specifies the size in bytes of the Java pool from which the Java memory manager allocates most Java state during runtime execution, is not necessary if you're not going to use Oracle's Java Virtual Machine (JVM). In that case, you can safely set this parameter to zero. Note - there is another alert you can use if you're using Java.
Active=0
AlertControl=Java_Pool_Megs_
LeftSideExpr=" Java_Pool_Megs "
RightSideExpr="0"
RelationalOp=>
Refreshes=1
[Database Probe Alert_17]
Name=Memory Sort Check
Desc=The "In memory sort" percentage has fallen below the minimum threshold value set. For best performance in OLTP systems, most sorts should occur solely within memory. DSS applications typically access large volumes of data and are thus expected to perform sorts to disk.
Active=1
AlertControl=Efficiency_Mem_Sorts_
LeftSideExpr=" Efficiency_Mem_Sorts "
RightSideExpr="80"
RelationalOp=<
Refreshes=1
[Database Probe Alert_18]
Name=Index Usage Check
Desc=The "Index Usage" percentage has fallen below the minimum threshold value set. For best performance in OLTP systems, many if not most data accesses should be able to utilize indexes. DSS applications typically access large volumes of data and are thus expected to make somewhat less use of indexes on a percentage basis. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the index usage percentage falls below 80%.
Active=1
AlertControl=Efficiency_Idx_Usage_
LeftSideExpr=" Efficiency_Idx_Usage "
RightSideExpr="80"
RelationalOp=<
Refreshes=1
[Database Probe Alert_19]
Name=ARCH Proc Not Running
Desc=The ARCH process is not running and the database is in ARCHIVELOG mode. This is a disaster waiting to happen. Once the Online Redo Log files fill up, the database will come to a grinding halt. The database will not be able to perform a log switch from the Nth log file to the 1st log file as that file will be waiting to be backed up to secondary storage before it can be reused. Thus the entire database will become locked up.
Active=1
AlertControl=ARCH_
LeftSideExpr=" ARCH "
RightSideExpr=" ArchiveLogMode "
RelationalOp=<
Refreshes=1
[Database Probe Alert_20]
Name=ARCH Proc Count High
Desc=Number of archive processes > 5 (the limit is 10). Verify that your hardware can actually handle that high an IO load.
Active=1
AlertControl=ARCH_Count
LeftSideExpr=" ARCH "
RightSideExpr="5"
RelationalOp=>
Refreshes=1
[Database Probe Alert_21]
Name=ARCH Proc Not Needed
Desc=The ARCH process is running and the database is in NOARCHIVELOG mode. This means that you have ARCH processes running even though they will be doing no work. These processes are thus unnecessary and can be eliminated. Set LOG_ARCHIVE_START = FALSE in your INIT.ORA file.
Active=1
AlertControl=Archive_Log_Mode
LeftSideExpr="( ArchiveLogMode  - 1 ) *  ARCH "
RightSideExpr="0"
RelationalOp=<
Refreshes=1
[Database Probe Alert_22]
Name=Hourly Log Switch Rate High
Desc=Your Online Redo Log file switch rate for the past hour greatly exceeds your number of Redo Log Groups. This may present a problem as your archive processes may not be able to copy the redo logs to secondary storage before they're needed again, essentially resulting in a hung database. This also may indicate a much higher transaction load than originally anticpated and might warrant additional consideration regarding database configuration parameters set in the INIT.ORA file.
Active=1
AlertControl=Log_Switches_Past_Hour_
LeftSideExpr=" Log_Switches_Past_Hour "
RightSideExpr=" Redo_Log_Files_Groups * 2"
RelationalOp=>
Refreshes=1
[Database Probe Alert_23]
Name=Daily Log Switch Rate High
Desc=Your Online Redo Log file switch rate for the past day greatly exceeds your number of Redo Log Groups. This may present a problem as your archive processes may not be able to copy the redo logs to secondary storage before they're needed again, essentially resulting in a hung database. This also may indicate a much higher transaction load than originally anticpated and might warrant additional consideration regarding database configuration parameters set in the INIT.ORA file.
Active=1
AlertControl=Log_Switches_Past_Day_
LeftSideExpr=" Log_Switches_Past_Day "
RightSideExpr=" Redo_Log_Files_Groups * 48"
RelationalOp=>
Refreshes=1
[Database Probe Alert_24]
Name=Too Few Tablespaces
Desc=The database may have too few tablespaces. A typical Oracle database should have at least the following five tablespaces: SYSTEM, RBS or UNDO, TEMP, one for user data and one for user indexes. In fact, there should probably be separate tablespaces for user data and user indexes per application or major subject area contained within that database.
Active=1
AlertControl=Data_Files_Tablespaces_
LeftSideExpr=" Data_Files_Tablespaces "
RightSideExpr="5"
RelationalOp=<
Refreshes=1
[Database Probe Alert_25]
Name=Too Many Datafiles
Desc=The database may have too many data files. A typical Oracle database should have just a few data files per tablespace. When a tablespace has lots of data files, it's often the case that the data file is being used as a generic container for too many unrelated objects.
Active=1
AlertControl=Data_Files_Datafiles_
LeftSideExpr=" Data_Files_Datafiles "
RightSideExpr=" Data_Files_Tablespaces * 2"
RelationalOp=>=
Refreshes=1
[Database Probe Alert_26]
Name=Database Getting Big
Desc=Total database data file size is getting relatively big. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the total database data file size passes half a terabyte.
Active=1
AlertControl=Data_Files_Megs_
LeftSideExpr=" Data_Files_Megs "
RightSideExpr="500000"
RelationalOp=>=
Refreshes=1
[Database Probe Alert_27]
Name=Database Filling Up
Desc=Total database data file percentage used is getting relatively tight. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the total database data file percentage used passes 80%.
Active=1
AlertControl=Data_Files_Percent_Used_
LeftSideExpr=" Data_Files_Percent_Used "
RightSideExpr="80"
RelationalOp=>=
Refreshes=1
[Database Probe Alert_28]
Name=Too Few Redo Log Groups
Desc=The database may have too few Online Redo Log Groups. A typical Oracle database must have at least two groups, but you should strongly consider more than two groups - especially when the database is in ARCHIVELOG mode. This might present a problem as your archive processes may not be able to copy the redo logs to secondary storage before they're needed again, essentially resulting in a hung database.
Active=1
AlertControl=Redo_Log_Files_Groups_
LeftSideExpr=" Redo_Log_Files_Groups "
RightSideExpr="2"
RelationalOp=<=
Refreshes=1
[Database Probe Alert_29]
Name=Mismatched Redo Log Size
Desc=The current Online Redo Log Group has a size that is different than the average for all the other groups. While this is permitable, it is nonetheless unusual. All the Online Redo Log Group and Member files should be the same size. It makes redo log tuning and troubleshooting easier when all the redo log group and member file sizes are the same.
Active=1
AlertControl=Redo_Log_Files_Current_
LeftSideExpr="" select bytes from v$log where group# =  Redo_Log_Files_Current ""
RightSideExpr="" select avg(bytes) from v$log where group# !=  Redo_Log_Files_Current ""
RelationalOp=<>
Refreshes=1
[Database Probe Alert_30]
Name=Too Small Redo Log Size
Desc=The Redo Log Group files appear to be of an average size that is smaller than required to meet Oracle's recommendation of size in order to experience a log switch about every 30 minutes. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the average online redo log file size is less than 10 MB.
Active=1
AlertControl=Redo_Log_Files_Megs_
LeftSideExpr=" Redo_Log_Files_Megs  /  Redo_Log_Files_Groups "
RightSideExpr="10"
RelationalOp=<
Refreshes=1
[Database Probe Alert_31]
Name=Disproportionate Redo Log Size
Desc=The current Online Redo Log Group has a size that is disproportionately larger than normal. While this is permitable, it is nonetheless unusual. All the Online Redo Log Group and Member files should be the same size. It makes redo log tuning and troubleshooting easier when all the redo log group and member file sizes are the same.
Active=1
AlertControl=Redo_Log_Files_Active_
LeftSideExpr=" Redo_Log_Files_Active "
RightSideExpr="100 /  Redo_Log_Files_Groups"
RelationalOp=>
Refreshes=1
[Database Probe Alert_32]
Name=Session Usage Near Limit
Desc=The database is nearing its maximum allowable session limit. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the percetage of current sessions used exceeds 90% of the total sessions allowed.
Active=1
AlertControl=Sessions_Total_
LeftSideExpr=" Sessions_Used  / Sessions_Max"
RightSideExpr=".9"
RelationalOp=>=
Refreshes=1
[Database Probe Alert_33]
Name=Too Few Active Sessions
Desc=The database has relatively very few sessions that are currently active. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the percentage of active sessions falls below 10% of the current sessions used.
Active=1
AlertControl=Sessions_Active_
LeftSideExpr=" Sessions_Active  /  Sessions_Used "
RightSideExpr=".1"
RelationalOp=<=
Refreshes=1
[Database Probe Alert_34]
Name=Too Many Locked Sessions
Desc=The database has relatively many sessions that are locked and waiting on resources. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the percentage of locked sessions exceeds 10% of the current sessions used.
Active=1
AlertControl=Sessions_Lock_Wait_
LeftSideExpr=" Sessions_Lock_Wait  /  Sessions_Used "
RightSideExpr=".1"
RelationalOp=>=
Refreshes=1
[Database Probe Alert_35]
Name=Process Usage Near Limit
Desc=The database is nearing its maximum allowable process limit. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the percentage of current processes used exceeds 90% of the total processes allowed.
Active=1
AlertControl=Processes_Total_
LeftSideExpr=" Processes_Used  /  Processes_Max "
RightSideExpr=".9"
RelationalOp=>=
Refreshes=1
[Database Probe Alert_36]
Name=Shared Process Usage Near Limit
Desc=The database is nearing its maximum allowable shared process limit. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the percetage of current shared processes used exceeds 90% of the total shared processes allowed.
Active=1
AlertControl=Processes_Shared
LeftSideExpr=" Processes_Shared_Used  /  Processes_Shared_Max "
RightSideExpr=".9"
RelationalOp=>=
Refreshes=1
[Database Probe Alert_37]
Name=Dispatcher Process Usage Near Limit
Desc=The database is nearing its maximum allowable dispatcher process limit. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the percentage of current dispatcher processes used exceeds 90% of the total dispatcher processes allowed.
Active=1
AlertControl=Processes_Dispatchers
LeftSideExpr=" Processes_Dispatchers_Used  /  Processes_Dispatchers_Max "
RightSideExpr=".9"
RelationalOp=>=
Refreshes=1
[Database Probe Alert_38]
Name=Parallel Process Usage Near Limit
Desc=The database is nearing its maximum allowable parallel process limit. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the percetage of current parallel processes used exceeds 90% of the total parallel processes allowed.
Active=1
AlertControl=Processes_Parallel
LeftSideExpr=" Processes_Parallel_Used  /  Processes_Parallel_Max "
RightSideExpr=".9"
RelationalOp=>=
Refreshes=1
[Database Probe Alert_39]
Name=Too Few Background Procs
Desc=The database appears to be missing some of the required background processes. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the background process count falls below 7. Note that this value is Oracle version dependent and that an older version of Oracle will require fewer minimum background processes.
Active=1
AlertControl=Processes_Background_
LeftSideExpr=" Processes_Background "
RightSideExpr="7"
RelationalOp=<
Refreshes=1
[Database Probe Alert_40]
Name=Dedicated Servers in MTS DB
Desc=Dedicated server processes have been detected in what appears to be a Multi-Threaded Server (MTS) database. While there is nothing inherently wrong with this occuring, it may require DBA review to be sure that it's appropriate. For example, certain DBA tasks require connecting to the database with a dedicated server and that may be what's happening. The real question is whether your applications are coded to use the correct connection style for the MTS database.
Active=1
AlertControl=Processes_Dedicated_
LeftSideExpr="Processes_Dispatchers_Used  *  Processes_Dedicated  "
RightSideExpr="0"
RelationalOp=>
Refreshes=1
[Database Probe Alert_41]
Name=Excessive PGA Consumption
Desc=The database has a relatively large amount of PGA memory allocated as compared to the SGA. While there is nothing inherently wrong with this occuring, it may require DBA review to be sure that it's appropriate. For example, the DBA may have set certain INIT.ORA parameters like the SORT_AREA_SIZE and not realized they apply per process - including parallel slave processes. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the percentage of PGA memory allocated exceeds 20% of the SGA memory allocated.
Active=1
AlertControl=PGA_Size_
LeftSideExpr=" PGA_Allocated  /  SGA_Size "
RightSideExpr=".2"
RelationalOp=>=
Refreshes=1
[Database Probe Alert_42]
Name=Inefficient PGA Allocation
Desc=The database is utilizing a relatively small portion of the PGA memory allocated. While there is nothing inherently wrong with this occuring, it may require DBA review to be sure that it's appropriate. For example, the DBA may have set certain INIT.ORA parameters (e.g. SORT_AREA_SIZE) larger than necessary - resulting in wasted memory. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the percentage of PGA memory used falls below 60% of the PGA memory allocated.
Active=1
AlertControl=PGA_Allocated_
LeftSideExpr=" PGA_Used  /  PGA_Max "
RightSideExpr=".6"
RelationalOp=<=
Refreshes=1
[Database Probe Alert_43]
Name=Too Small SGA Allocation
Desc=The SGA memory allocation is suspiciously small, which can result in poor database performance. Oracle stores information in memory caches and on disk. Memory access is much faster than disk access. Disk scans (physical I/O) take a significant amount of time, compared with memory access, typically in the order of 10 milliseconds. Physical I/O also increases the CPU resources required, because of the path length in device drivers and operating system event schedulers. For this reason, it is more efficient for data requests for frequently accessed objects to be satisfied solely by memory, rather than also requiring disk access. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the SGA allocated falls below 128 MB.
Active=1
AlertControl=SGA_Size_
LeftSideExpr=" SGA_Size "
RightSideExpr="128"
RelationalOp=<
Refreshes=1
[Database Probe Alert_44]
Name=Overall DB Cache Waste
Desc=The database is using a low percentage of the overall database buffer cache memory allocated. While there is nothing inherently wrong with this occuring, it may require DBA review to be sure that it's appropriate. For example, the DBA may have set certain INIT.ORA parameters larger than is actually necessary - thus less memory might be allocated while not negatively impacting the hit ratio. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the percentage of memory used falls below 60% of the memory allocated.
Active=1
AlertControl=DB_Buffer_Cache_Overall
LeftSideExpr=" DB_Buffer_Cache_Overall_Used  /  DB_Buffer_Cache_Overall_Max "
RightSideExpr=".6"
RelationalOp=<=
Refreshes=1
[Database Probe Alert_45]
Name=Default DB Cache Waste
Desc=The database is using a low percentage of the default database buffer cache memory allocated. While there is nothing inherently wrong with this occuring, it may require DBA review to be sure that it's appropriate. For example, the DBA may have set certain INIT.ORA parameters larger than is actually necessary - thus less memory might be allocated while not negatively impacting the hit ratio. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the percentage of memory used falls below 60% of the memory allocated.
Active=1
AlertControl=DB_Buffer_Cache_Default
LeftSideExpr="  DB_Buffer_Cache_Default_Used  /  DB_Buffer_Cache_Default_Max "
RightSideExpr=".6"
RelationalOp=<=
Refreshes=1
[Database Probe Alert_46]
Name=Recycle DB Cache Waste
Desc=The database is using a low percentage of the recycle database buffer cache memory allocated. While there is nothing inherently wrong with this occuring, it may require DBA review to be sure that it's appropriate. For example, the DBA may have set certain INIT.ORA parameters larger than is actually necessary - thus less memory might be allocated while not negatively impacting the hit ratio. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the percentage of memory used falls below 60% of the memory allocated.
Active=1
AlertControl=DB_Buffer_Cache_Recycle
LeftSideExpr=" DB_Buffer_Cache_Recycle_Used  /  DB_Buffer_Cache_Recycle_Max "
RightSideExpr=".6"
RelationalOp=<=
Refreshes=1
[Database Probe Alert_47]
Name=Keep DB Cache Waste
Desc=The database is using a low percentage of the keep database buffer cache memory allocated. While there is nothing inherently wrong with this occuring, it may require DBA review to be sure that it's appropriate. For example, the DBA may have set certain INIT.ORA parameters larger than is actually necessary - thus less memory might be allocated while not negatively impacting the hit ratio. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the percentage of memory used falls below 60% of the memory allocated.
Active=1
AlertControl=DB_Buffer_Cache_Keep
LeftSideExpr=" DB_Buffer_Cache_Keep_Used  /  DB_Buffer_Cache_Keep_Max "
RightSideExpr=".6"
RelationalOp=<=
Refreshes=1
[Database Probe Alert_48]
Name=Library Cache Waste
Desc=The database is using a low percentage of the shared pool library cache cache memory allocated. While there is nothing inherently wrong with this occuring, it may require DBA review to be sure that it's appropriate. For example, the DBA may have set certain INIT.ORA parameters larger than is actually necessary - thus less memory might be allocated while not negatively impacting the hit ratio. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the percentage of memory used falls below 60% of the memory allocated.
Active=1
AlertControl=Shared_Pool_Lib_Cache
LeftSideExpr=" Shared_Pool_Lib_Cache_Used  /  Shared_Pool_Lib_Cache_Used "
RightSideExpr=".6"
RelationalOp=<=
Refreshes=1
[Database Probe Alert_49]
Name=Shared Pool Too Small 1
Desc=The shared pool is probably too small. The main components of the shared pool are the library cache and the dictionary cache. The library cache stores the executable (parsed or compiled) form of recently referenced SQL and PL/SQL code. The dictionary cache stores data referenced from the data dictionary. A cache miss on the data dictionary cache or library cache is more expensive than a miss on the buffer cache. For this reason, the shared pool should be sized to ensure that frequently used data is cached. A number of features make large memory allocations in the shared pool: for example, the shared server, parallel query, or Recovery Manager. Oracle recommends segregating the SGA memory used by these features by configuring a distinct memory area, called the large pool. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the shared pool size falls below 40 MB.
Active=1
AlertControl=Shared_Pool_Overall
LeftSideExpr=" Shared_Pool_Overall_Total "
RightSideExpr="40"
RelationalOp=<=
Refreshes=1
[Database Probe Alert_50]
Name=Low Dict Cache Allocation
Desc=The dictionary cache is probably too small. The dictionary cache stores data referenced from the data dictionary. A cache miss on the data dictionary cache or library cache is more expensive than a miss on the buffer cache. For this reason, the shared pool should be sized to ensure that frequently used data is cached. However, many of the caches in the shared pool automatically increase or decrease in size as needed, including the library cache and the dictionary cache. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the cache size size falls below 2 MB.
Active=1
AlertControl=Shared_Pool_Dict_Cache
LeftSideExpr=" Shared_Pool_Dict_Cache_Total "
RightSideExpr="2"
RelationalOp=<
Refreshes=1
[Database Probe Alert_51]
Name=Low SQL Area Allocation
Desc=The SQL area is probably too small. When an application makes a parse call for a SQL statement, if the parsed representation of the SQL statement does not already exist in the library cache or if it has been previously parsed but aged out of the cache then Oracle parses the statement and stores the parsed form in the SQL area. This is known as a hard parse. Resources required for a hard parse include additional CPU, library cache latch gets, and shared pool latch gets. So it's desirable to perform soft parses. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the SQL area size size falls below 8 MB.
Active=1
AlertControl=Shared_Pool_SQL_Area
LeftSideExpr=" Shared_Pool_SQL_Area_Total "
RightSideExpr="8"
RelationalOp=<
Refreshes=1
[Database Probe Alert_52]
Name=Excess Shared Pool Free
Desc=The database has a large percentage of the shared pool free memory. While there is nothing inherently wrong with this occuring, it may require DBA review to be sure that it's appropriate. For example, the DBA may have set certain INIT.ORA parameters larger than is actually necessary. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the percentage of shared pool free memory exceeds 40% of the shared pool memory allocated.
Active=1
AlertControl=Shared_Pool_Free
LeftSideExpr=" Shared_Pool_Free_Total  /  Shared_Pool_Overall_Total "
RightSideExpr=".4"
RelationalOp=>=
Refreshes=1
[Database Probe Alert_53]
Name=Low Large Pool Allocation
Desc=The large pool is probably too small. A number of features make large memory allocations in the shared pool: for example, the shared server (MTS), parallel query, or Recovery Manager. Oracle recommends segregating the SGA memory used by these features by configuring a distinct and properly sized memory area, called the large pool. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the large pool size falls below 8 MB.
Active=1
AlertControl=Large_Pool_Megs_
LeftSideExpr=" Large_Pool_Megs "
RightSideExpr="8"
RelationalOp=<
Refreshes=1
[Database Probe Alert_54]
Name=Too Small Large Pool 1
Desc=The large pool is probably too small. A number of features make large memory allocations in the shared pool: for example, the shared server (MTS), parallel query, or Recovery Manager. Oracle recommends segregating the SGA memory used by these features by configuring a distinct and properly sized memory area, called the large pool. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the low large pool used percentage exceeds 80% of the large pool size.
Active=1
AlertControl=Large_Pool_Cur_Used_
LeftSideExpr=" Large_Pool_Cur_Used  /  Large_Pool_Megs "
RightSideExpr=".8"
RelationalOp=>=
Refreshes=1
[Database Probe Alert_55]
Name=Too Small Large Pool 2
Desc=The large pool is probably too small. A number of features make large memory allocations in the shared pool: for example, the shared server (MTS), parallel query, or Recovery Manager. Oracle recommends segregating the SGA memory used by these features by configuring a distinct and properly sized memory area, called the large pool. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the high large pool used percentage exceeds 80% of the large pool size.
Active=1
AlertControl=Large_Pool_Max_Used_
LeftSideExpr=" Large_Pool_Max_Used  /  Large_Pool_Megs "
RightSideExpr=".8"
RelationalOp=>=
Refreshes=1
[Database Probe Alert_56]
Name=Low Overall DB Cache Hit Ratio
Desc=The database is currently experiencing a low percentage of overall database buffer cache hit ratio. This may translate to slower database performance since Oracle may be doing more physical IO than if a larger cache were allocated. As a general rule, investigate increasing the size of the cache if the cache hit ratio is low and your application has been tuned to avoid performing full table scans. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the hit ratio percentage falls below 85%.
Active=1
AlertControl=DB_Buffer_Cache_Overall_Hit_
LeftSideExpr=" DB_Buffer_Cache_Overall_Hit "
RightSideExpr="85"
RelationalOp=<
Refreshes=1
[Database Probe Alert_57]
Name=Low Default DB Cache Hit Ratio
Desc=The database is currently experiencing a low percentage of default database buffer cache hit ratio. This may translate to slower database performance since Oracle may be doing more physical IO than if a larger cache were allocated. As a general rule, investigate increasing the size of the cache if the cache hit ratio is low and your application has been tuned to avoid performing full table scans. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the hit ratio percentage falls below 85%.
Active=1
AlertControl=DB_Buffer_Cache_Default_Hit_
LeftSideExpr=" DB_Buffer_Cache_Default_Hit "
RightSideExpr="85"
RelationalOp=<
Refreshes=1
[Database Probe Alert_58]
Name=Low Keep DB Cache Hit Ratio
Desc=The database is currently experiencing a low percentage of keep database buffer cache hit ratio. This may translate to slower database performance since Oracle may be doing more physical IO than if a larger cache were allocated. As a general rule, investigate increasing the size of the cache if the cache hit ratio is low and your application has been tuned to avoid performing full table scans. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the hit ratio percentage falls below 85%. Note - the DBA may simply have allocated a keep pool and not placed any objects into it or the applications may not be accessing keep pool objects.
Active=1
AlertControl=DB_Buffer_Cache_Keep_Hit_
LeftSideExpr=" DB_Buffer_Cache_Keep_Hit "
RightSideExpr="85"
RelationalOp=<
Refreshes=1
[Database Probe Alert_59]
Name=Low Recycle DB Cache Hit Ratio
Desc=The database is currently experiencing a low percentage of recycle database buffer cache hit ratio. This may translate to slower database performance since Oracle may be doing more physical IO than if a larger cache were allocated. As a general rule, investigate increasing the size of the cache if the cache hit ratio is low and your application has been tuned to avoid performing full table scans. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the hit ratio percentage falls below 85%. Note - the DBA may simply have allocated a recycle pool and not placed any objects into it or the applications may not be accessing recycle pool objects.
Active=1
AlertControl=DB_Buffer_Cache_Recycle_Hit_
LeftSideExpr=" DB_Buffer_Cache_Recycle_Hit "
RightSideExpr="85"
RelationalOp=<
Refreshes=1
[Database Probe Alert_60]
Name=Excessive Redo Log Buffer Size
Desc=The redo log buffer appears to be too large. Applications that insert, modify, or delete large volumes of data usually need to change the default log buffer size. The log buffer is small compared with the total SGA size, and a modestly sized log buffer can significantly enhance throughput on systems that perform many updates. A reasonable first estimate for such systems is to make the log buffer 1 MB. On most systems, sizing the log buffer larger than 1 MB does not provide any performance benefit. Increasing the log buffer size does not have any negative implications on performance or recoverability. It merely uses extra memory.
Active=1
AlertControl=Redo_Log_Buffer_Megs_
LeftSideExpr=" Redo_Log_Buffer_Megs "
RightSideExpr="1"
RelationalOp=>
Refreshes=1
[Database Probe Alert_61]
Name=Excessive Redo Allocation Retries
Desc=The value of redo buffer allocation retries should be near zero over an interval. If this value increments consistently, then processes have had to wait for space in the redo log buffer. The wait can be caused by the log buffer being too small or by checkpointing. Increase the size of the redo log buffer, if necessary, by changing the value of the initialization parameter LOG_BUFFER.  Alternatively, improve the checkpointing or archiving process.
Active=1
AlertControl=Redo_Log_Buffer_Retries_
LeftSideExpr=" Redo_Log_Buffer_Retries "
RightSideExpr="0"
RelationalOp=>
Refreshes=2
[Database Probe Alert_62]
Name=Excessive Redo Allocation Waits
Desc=The value of redo buffer allocation waits should be near zero over an interval. If this value increments consistently, then processes have had to wait for space in the redo log buffer. The wait can be caused by the log buffer being too small or by checkpointing. Increase the size of the redo log buffer, if necessary, by changing the value of the initialization parameter LOG_BUFFER.  Alternatively, improve the checkpointing or archiving process.
Active=1
AlertControl=Redo_Log_Buffer_Waits_
LeftSideExpr=" Redo_Log_Buffer_Waits "
RightSideExpr="0"
RelationalOp=>
Refreshes=2
[Database Probe Alert_63]
Name=Shared Pool Too Small 2
Desc=The shared pool is probably too small. The main components of the shared pool are the library cache and the dictionary cache. The library cache stores the executable (parsed or compiled) form of recently referenced SQL and PL/SQL code. The dictionary cache stores data referenced from the data dictionary. A cache miss on the data dictionary cache or library cache is more expensive than a miss on the buffer cache. For this reason, the shared pool should be sized to ensure that frequently used data is cached. A number of features make large memory allocations in the shared pool: for example, the shared server, parallel query, or Recovery Manager. Oracle recommends segregating the SGA memory used by these features by configuring a distinct memory area, called the large pool. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the miscellaneous shared pool components size exceed 40% of the shared pool.
Active=1
AlertControl=Shared_Pool_Misc
LeftSideExpr=" Shared_Pool_Misc_Total  /  Shared_Pool_Overall_Total "
RightSideExpr=".4"
RelationalOp=>=
Refreshes=1
[Database Probe Alert_64]
Name=Low Dict Cache Hit Ratio
Desc=The database is currently experiencing a low percentage of dictionary cache hit ratio. This may translate to slower database performance since Oracle may be doing more physical IO than if a larger cache were allocated. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the hit ratio percentage falls below 95%. Note - the hit ratio may be less than 95% after initial database startup as the cache is empty, but should stabilize around the desired percentage after a short while.
Active=1
AlertControl=Shared_Pool_Dict_Cache_Hit_
LeftSideExpr=" Shared_Pool_Dict_Cache_Hit "
RightSideExpr="95"
RelationalOp=<
Refreshes=1
[Database Probe Alert_65]
Name=Low Library Cache Hit Ratio
Desc=The database is currently experiencing a low percentage of library cache hit ratio. This may translate to slower database performance since Oracle may be doing more physical IO than if a larger cache were allocated. Specifically, this means that SQL statements that are needed are being "aged out" of the cache. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the hit ratio percentage falls below 85%.
Active=1
AlertControl=Shared_Pool_Lib_Cache_Hit_
LeftSideExpr=" Shared_Pool_Lib_Cache_Hit "
RightSideExpr="85"
RelationalOp=<
Refreshes=1
[Database Probe Alert_66]
Name=High Block Mods Ratio
Desc=The database is experiencing a period of relatively high block modification versus get activity. This is usually the case during a high volume data load or other period of unusual insert/update activity. While there is nothing inherently wrong with this, the DBA may still want to examine the overall database load and see if there are jobs that can be scheduled so as not to overlap. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the block mods to get ratio exceeds 25%.
Active=1
AlertControl=Block_Mods_Sec_
LeftSideExpr=" Block_Mods_Sec "
RightSideExpr=" .25 * Block_Gets_Sec "
RelationalOp=>
Refreshes=2
[Database Probe Alert_67]
Name=High Physical Writes Ratio
Desc=The database is experiencing a period of relatively high physical write versus read activity. This is usually the case during a high volume data load or other period of unusual insert/update activity. While there is nothing inherently wrong with this, the DBA may still want to examine the overall database load and see if they are jobs that can be scheduled so as not to overlap. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the physical writes to reads ratio exceeds 25%.
Active=1
AlertControl=Physical_Writes_Sec
LeftSideExpr=" Phys_wr_sec "
RightSideExpr=".25 *  Phys_rd_sec "
RelationalOp=>
Refreshes=2
[Database Probe Alert_68]
Name=Excessive Log Writer Writes
Desc=The database is experiencing a period of relatively high log writer activity. This is usually the case during a high volume data load or other period of unusual insert/update activity. While there is nothing inherently wrong with this, the DBA may still want to examine the overall database load and see if there are jobs that can be scheduled so as not to overlap. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the log writer writes per second exceeds 1000.
Active=1
AlertControl=LGWR_Count
LeftSideExpr=" LGWR_wr_sec "
RightSideExpr="1000"
RelationalOp=>
Refreshes=2
[Database Probe Alert_69]
Name=Excessive Physical Reads
Desc=The database is experiencing a period of relatively high physical read activity. This is usually the case during any period of unusually high select activity or if there is excessive full table scan activity. While there is nothing inherently wrong with this, the DBA may still want to examine the overall database load and see if there are jobs that can be scheduled so as not to overlap. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the physical reads per second exceeds 5000.
Active=1
AlertControl=Physical_Reads_Sec
LeftSideExpr=" Phys_rd_sec "
RightSideExpr="5000"
RelationalOp=>
Refreshes=2
[Database Probe Alert_70]
Name=Excessive Block Gets
Desc=The database is experiencing a period of relatively high block get activity. This is usually the case during any period of unusually high select activity or if there is excessive full table scan activity. While there is nothing inherently wrong with this, the DBA may still want to examine the overall database load and see if there are jobs that can be scheduled so as not to overlap. This is an arbitrary alert value to be defined by the user. The default triggers an alert when the block gets per second exceeds 5000.
Active=1
AlertControl=Block_Gets_Sec_
LeftSideExpr=" Block_Gets_Sec "
RightSideExpr="5000"
RelationalOp=>
Refreshes=2
